[レポート] Amazon におけるオブザーバビリティのベストプラクティス #COP343 #reinvent

アノテーション テクニカルサポートの川崎です。

本記事は AWS re:Invent 2022 のセッションレポートとなります。

概要

このセッションでは、完璧な粒度のオブザーバビリティを実現するための Amazon の終わりのないジャーニーについて学びます。 このセッションでは、チームがシステムの健全性を高レベルで評価する方法から、ズームインして単一のリクエストの詳細を理解する方法まで、Amazon でのモニタリングの全範囲をカバーします。 メトリクス、ログ、トレースのベストプラクティスと、これらのシグナルを使用してオペレーショナルエクセレンスを達成する方法を学びます。

セッション動画

セッション資料

Observability best practices at Amazon

アジェンダ

• Amazon の DevOps フライホイール
• 根本原因を見つけ出す
• あらゆる箇所から測定

Amazon の DevOps フライホイール

1 はじめに

このセッションでは、Amazonにおけるオブザーバビリティの取り組みやストーリーを共有し、モニタリング全体にわたる話題をカバーします。Amazonにおいてオブザーバビリティは、お客様の経験を本当に理解する上で非常に重要です。指標を活用してシステム上での顧客の経験を観察し、共感することができます。また、トラブルシューティングが必要な事柄についても触れます。 さらに、オブザーバビリティツールを利用して問題解決を行い、様々な困難を乗り越えられる方法について示します。そして、お客様の目線を正確に理解するために、あらゆる場所から情報収集を行い、業務を適切な視点で見ているかどうかを常に質問しています。 Amazonでは、オブザーバビリティに強く取り組んでおり、その理由をお伝えできればと考えています。このセッションでは、オブザーバビリティの基本とAmazonがどのように取り組んでいるかについて解説します。また、実際にどのような場面でオブザーバビリティシステムが使われていて、それらがどのように連動して改善された経験や運用、そして最終的には良い顧客体験につながるかをお話します。 私自身、オブザーバビリティを実行中のシステムを評価する方法ではなく、顧客体験を評価する方法として捉えることが好きです。これを心がけることで、よりお客様の立場に立ってサービスの提供ができると考えています。

2 顧客体験の観察

顧客体験の観察とオブザーバビリティの重要性について説明します。システムの特性を考慮して、可用性や待ち時間などの測定と共感が重要です。過去10年間、Amazonで働いている著者は、顧客のために優れたオブザーバビリティシステムを構築してきました。この講演では、様々なシステムや解決策を紹介します。これらの解決策は、CloudWatchのサービスにも適用できます。 Amazonでは、開発者としてのロールが持つ　DevOps　モデルにより、すべてのサービスを所有し運用しています。このロールでは、多くの時間をかけて多くのことを学びましたが、サービスの運用文化に近づくことで、初日からより良いサービスが構築できると確信しています。 オブザーバビリティは、アラームやインシデントの発生時に特に重要です。適切なアラーム設定によって、チームが顧客に影響が出る前に関与できるようになります。運営イベントでは、メトリクス、ログ、トレースなどのオブザーバビリティシステムを使用してトラブルシューティングし、特定の問題を解決していきます。 イベント後には、オブザーバビリティデータをもとに自問自答を行い、改善の機会を探ります。Amazonにおいては、COE（Correction of Error、エラーの根本原因分析）を行い、サービスやプロセスの継続的な改善を目指しています。これには、五つの問い（５つのなぜ）という手法が用いられます。この手法はトヨタ生産方式で始まり、リーン生産などの様々な方法論にも応用されています。 五つの問いに答えるためには、メトリクスとログ分析を利用して、システムの証拠を収集し分析します。このプロセスを通じて、新しい学習を行ったり、テレメトリデータの改善が必要だと気づくことがよくあります。新しいデータを生成し、次回の問題をより迅速に解決できるようにすることがオブザーバビリティの目的です。

3 週次の運営会議

オブザーバビリティデータがよく活用される場の1つは、運用レビュー会議です。これらの会議は組織全体で様々なレベルで行われ、個々のチームからはじまり、組織レベルのレビューへと取り組まれ、最終的には毎週水曜日のAWS全体の運用レビュー会議にて最高点に達します。この会議には何千ものエンジニアと上級管理職が参加し、サービスの運用文化と顧客体験に近づくことができます。 すべての会議で共通しているのは、レビュー対象のサービスの顧客体験をよく表しているダッシュボードを確認し、問題の深層理解や顧客体験の改善を行うために多くの質問がされることです。また、前述の　COE の確認や、会社全体で発生しているベストプラクティスの共有や運用上の成功を祝うことも行われます。 Amazonは大量のオブザーバビリティデータを収集していますが、例として、CloudWatchは現在、9,000兆を超えるメトリクス観測を取り込み、月間5エクサバイトを超えるログデータを取り込んでいます。これは驚くべきスケールであり、地球上の80億人を超える人々に対して1人あたり100万を超える観測値があることを意味します。 これらの膨大なデータの収集は容易ではありませんが、お客様が素晴らしい体験をしているかどうかの判断に役立ちます。そして、これはAmazonの主要なリーダーシップ原則の多くに訴えかけ、力を与えるものです。例えば、多くのことを正しく行い、深く掘り下げ、最高の基準を主張するなどです。

4 オブザーバビリティのサイクル

オブザーバビリティのサイクルについては、運用の改善という文化的なフライホイールとして表すことができます。このフライホイールは、オブザーバビリティシステムを用いて、サービスを計測することで回されます。メトリクス、ログ、トレースを利用し、アラームやダッシュボードを消費します。新しいインストルメンテーション（計測）を簡単に追加する操作の維持が重要です。 システムを操作することで、経験を積み、お客様にとって何が重要かを学びます。そして、オブザーバビリティを利用して、警告を発し、影響を軽減し、さらなる質問をします。学習サイクルをスピードアップすることで、次回の問題をより迅速に解決できます。 オブザーバビリティのジャーニーには、多くのエントリーポイントがあります。それはアラームやダッシュボード、サービスマップを利用した分散システムの概要に始まります。最終的には、ログ分析を行い、実際の例外や問題の原因を特定します。 トレーシングや分散トレーシングについては、Amazonでの活用方法や、ダッシュボードを使用して適切な問題を見つける方法について、いくつかのヒントが提供されています。追跡やダッシュボードから適切な問題対象を見つけるためには、それぞれを単独で使用することも、組み合わせることもあります。 オブザーバビリティを効果的に活用することで、運用上の理解と改善の文化を実現し、最終的には顧客体験の向上につながります。

根本原因を見つけ出す

5 分散システムに関する推論

分散システムに関する推論という図では、日常業務でよく遭遇する典型的な分散システムが示されています。このシステムにはロードバランサーが含まれており、その背後にはフロントエンドフリートが存在していて、さらにいくつかのLambdaを使用しています。また、キューイングやポーリングフリートも設置されています。 しかし、この比較的単純なサービスでも、パフォーマンスに関する問題が発生しうる場所はたくさんあり、問題の原因を特定するのは容易ではありません。こうした状況で役立つのがトレースという手法です。分散トレーシングを用いることで、システム全体に関する深い洞察が可能になります。 このようなトレースを利用することで、オブザーバビリティが向上し、システムの挙動に関する問題や遅延の原因を特定しやすくなります。分散システムがより複雑になることで、トレースを利用して解決しなければならない問題や課題も増えていくでしょう。 分散トレーシングを活用すれば、ロードバランサーやフロントエンドフリート、Lambda、キューイングシステム、ポーリングフリートといった複数のコンポーネント間でのやりとりや処理の遅延を特定し、改善策を考えることができます。 要約すると、典型的な分散システムでは、ロードバランサーやフロントエンドフリートなどの複数のコンポーネントが含まれており、パフォーマンスに問題が発生する可能性があります。しかし、分散トレーシングを利用することで、これらの問題を特定しやすくなるというメリットがあります。このため、分散トレーシングを適切に活用することで、システム全体のオブザーバビリティを向上させることができます。

6 分散トレース

分散システムを介したリクエストの動きについて説明します。リクエストに識別子を付けることで追跡が可能となり、トレースIDがリクエストごとに呼び出されます。リクエストがシステムを通過する際、各コンポーネント間でトレースIDが受け渡され、これによりシステム全体のパフォーマンス関連のタイミング情報やメトリクスを収集できます。その結果、早期警告サインやパフォーマンスのボトルネックを発見することが可能となります。 トレースの利用によって、システム全体の相互作用に関するタイミングやメトリクスの強力な要約が得られます。特定のトレースを詳細に調べることで、リクエストがシステムをどのように通過したかを把握することができます。また、すべてのトレースを1つのビューにまとめることもできます。例えば、X-Ray ではこれをサービスマップと呼んでいます。これにより、分散システム全体のトラブルシューティングが容易になります。 トレースを使うことで、問題が発生している箇所を特定し、特定の問題点やサービスのダッシュボードにアクセスすることができます。現在のAmazonでは、ダッシュボードが重要視されています。ほとんどのチームでは、サービスの様々な側面を最善に示すために、数十のダッシュボードが存在します。 Amazonのダッシュボードに関する考え方について説明します。最もシンプルなサービスを除いて、多くの独自のダッシュボードがあり、サービスのパフォーマンスと健全性に関する全体像が提供されます。このビューにより、システムの動作やパフォーマンスが様々な視点から、さまざまな時間間隔で理解できます。また、カスタマーエクスペリエンスから逆算し、ダッシュボードの階層を構築します。上位レベルから始めて、下層のサービスの側面について詳細に調べていくことになります。これにより、オブザーバビリティが向上し、システムの問題点を効率的に特定できるようになります。

7 カスタマー エクスペリエンス ダッシュボード

運用上のイベントにおいて、問題解決の過程で人々がさまざまなロールを引き受けることがよくあります。ビジネスリーダーは、進行中の影響に関するお客様とのコミュニケーションや通知に追われています。一方、サービスチームやエンジニアリングチームは、根本的な問題を軽減し、サービスをできるだけ早く正常な状態に戻すために忙しく働いています。 カスタマーエクスペリエンスのトップレベルのビューを持つことは、両チームにとって貴重な意義があります。これによって、ビジネスリーダーは効果的なコミュニケーションを行い、技術チームは実行しているアクションがカスタマーエクスペリエンスを向上させているかどうかを把握することができます。 優れたカスタマーエクスペリエンスダッシュボードは、サービスが提供する主要なカスタマーエクスペリエンスに焦点を当てています。それだけでなく、顧客への影響の広さと深さについても非常に明確です。オブザーバビリティの観点からも大切な概念で、適切な情報を提供することで改善の効果が出やすくなります。 以上の説明から、「カスタマーエクスペリエンスダッシュボード」は、ビジネスリーダーと技術チームが問題解決の過程で効率的に働くために重要な役割（ロール）を果たしていることがわかります。このダッシュボードは、適切なコミュニケーションや情報共有を促進し、カスタマーエクスペリエンスの向上に繋がるアクションが実行されることをサポートしています。そのため、オブザーバビリティに関する知識や技術の進展が、今後のダッシュボード作成においてさらに重要になることが予想されます。

8 システムレベルのダッシュボード

ウェブベースのサービスへアクセスする際には、通常UIまたはAPIエンドポイントを通じて行います。このため、専用のシステムレベルのダッシュボードには、オペレーターがシステムの状況を把握できる十分なデータが表示されている必要があります。 また、顧客向けのエンドポイントは正常に動作していることが求められます。これによって、オブザーバビリティを確保し、システムの問題解決や効率的な運用が可能になります。このようなシステムレベルのダッシュボードの整備は、サービス運用において重要な要素です。

9 マイクロサービス ダッシュボード

マイクロサービスダッシュボードの構築を通じて、カスタマーエクスペリエンスの迅速で包括的な評価が促進されます。単一のサービスインスタンスやセル、パーティション内を見ることで、オペレーターは運用イベント中に無関係な情報に気を取られることが少なくなります。さらに、特定のマイクロサービスに依存する他のマイクロサービスも表示することができます。 「オブザーバビリティ」を重視したマイクロサービスダッシュボード設計により、組織はシステム全体の状態とパフォーマンスについて迅速に把握できるようになります。これによって、問題の特定と対策が短時間で行えるようになり、カスタマーエクスペリエンスの質を向上させることができます。 また、「オブザーバビリティ」に重点を置いたダッシュボードには、各サービスのヘルス状態やメトリクス、トレーシング情報がわかりやすく表示され、運用チームがすばやく異常を検知し、対処できるようになります。特定のマイクロサービスに問題が発生した際には、それに関連する他のマイクロサービスも同時に確認できるため、迅速なトラブルシューティングが可能です。 このようなダッシュボードを活用することで、組織はマイクロサービス間の相互依存性を把握しやすくなり、全体のアーキテクチャの理解が深まります。さらに、運用チームはセルやパーティションの範囲に限定された視点で分析することができるため、無関係な情報に混乱されずに効率的に対応を行うことができます。 マイクロサービスダッシュボードの導入によって、組織はカスタマーエクスペリエンスの向上だけでなく、運用管理の効率化やシステム全体の信頼性向上にも寄与できます。組織の目的やニーズに合わせたダッシュボード設計が、マイクロサービスアーキテクチャをより強固で効率的なものにするための鍵となっています。

10 キャパシティ ダッシュボード

チームが使用しているリソースやサービスの量を表示できるキャパシティダッシュボードが構築されています。これにより、サービスの長期的なキャパシティプランニングと予測を行うことができます。例えば、十分なコンピューティングとストレージを確保するためです。 ダッシュボードは非常に多くあり、ここで紹介したもの以外にもたくさん存在します。しかし、重要なことは、これらのダッシュボードによって、常に午前3時に発生する運用イベント中に必要なデータをすばやく入手できることです。運用イベント中に適切なメトリクスを探しに行く必要がなく、ストレスになる可能性を軽減できます。

11 ダッシュボードのデザイン

Amazonでは長年にわたってダッシュボードの構築を行っており、その中でチームに最も効果的な要素を学んできました。以下は、そのポイントを簡単にまとめたものです。

• 時系列グラフを使用し、システムのパフォーマンスがいつどの程度変化したかをチームで簡単に視覚化できるようにすることが重要です。
• 重要なデータは、ダッシュボードの上部に配置し、それ以外のデータは下部に配置します。
• チームにとって簡単にすべての重要なデータを表示できるようにし、水平スクロールの必要性を避けます。
• 一貫したタイムゾーンを使用し、たとえばUTCタイムゾーンを使用してチーム間やイベント間で関連付けが容易になるようにします。
• グラフにSLAやSLOの注釈を付け、明確に理解できるようにします。
• ダッシュボードに説明テキストを追加し、理解しやすくすることが重要です。

また、y軸が過負荷にならないように複数の時系列を使用し、異なるスケールの類似指標の比較が困難な場合は、別のグラフを作成して分析しやすくします。ダッシュボードをシンプルに保ち、これらの要素を複数のダッシュボードに分割することが役立ちます。 運用イベント中にメトリクスの確認が容易であることが重要であり、事前に詳細なダッシュボードを構築することが推奨されます。ダッシュボードを継続的に検査および改良する文化を構築することも重要であり、Infrastructure-is-Codeアプローチを使用してプログラムでダッシュボードを管理することが1つの方法です。 また、運用会議においてランダムにサービスを選択し監査する方式も効果的です。これにより、各チームは運用レビューの準備とダッシュボードの詳細について話す必要があります。運用を可視化するためのダッシュボード構築に関心がある場合は、Amazon Builders' Library の記事「運用を可視化するためのダッシュボードの構築」を参照してください。 オブザーバビリティを向上させるためには、メトリクスの使用が重要です。メトリクスを使用してドリルダウンを行うことで、関心があり問題があると思われる部分を特定し、より深く理解することができます。

12 すべてをログに記録：埋め込みメトリクスフォーマット（EMF）

メトリクスがどのように機能し、どのように表示されるかを理解するために、まずメトリクスがどこから来たのかをお話ししましょう。メトリクスは、コードやシステムのインストルメンテーション（計測）から得られます。Amazonでは、すべてのアプリケーションやサービスのリクエストに関して、一連のインストルメンテーションを収集し、最終的にそれらをファイルに書き出します。これらは構造化されたログファイルの形を取ります。AmazonのCloudWatchに組み込まれたメトリクス形式の1つです。 構造化ログファイルを別の形式に解析するために、さまざまな方法があります。インストルメンテーションは一元化され、要求の間に何が起こったのか、何があったのか、その間に何をしていたのかといった事実が記録されます。そして、それぞれのログレコードには、メトリクスシステムがこれらの事実をどのように変換するかが示されます。例えば、どの事実をメトリクスに変換し、どのように分解するかなどです。これがどのような意味を持つかというと、メトリクスはシステムの動作を把握するための重要な情報源であり、それらを分析することでシステムのパフォーマンスを改善することができます。

13 例: シンプルな Webサービスのコード

実際のインストルメンテーションからどのように進んで、コードにたどり着くのかを見ていきましょう。例として、eコマースサイトの商品カタログサービスを考えます。このサービスは、get product infoなどのAPIを提供し、サイト上に表示される商品情報を返します。 しかし、この実装コードだけでは、サービスの操作について完全に理解することはできません。サービスで何が起こっているのか、リクエストが失敗した理由や遅延の原因など、手がかりが得られません。また、リクエストがキャッシュに届いているか、キャッシュから有益な情報を取得することができたのか、それともデータベースに戻る必要があったのかなど、多くの疑問が残ります。 成功した場合や失敗した場合の理由、タイムアウトが発生したかどうか、データベースのクエリにかかった時間など、トラブルシューティングやデバッグ、影響の軽減に関する情報が不足しています。このため、効果的なオブザーバビリティを確保することが難しいと言えるでしょう。

14 例: コードのインストルメンテーション（計測）

実際にコードに多くを追加するわけではないものの、非常に重要な要素であるインストルメンテーション（計測）について説明します。Amazonでは、会社全体で共通のメトリクスライブラリを使用しており、オブジェクトやメトリクスオブジェクトのインスタンスを新しいリクエストごとに作成して、コードに渡します。 このメトリクスオブジェクトは、SDKやキャッシングライブラリを使用してリモート呼び出しやキャッシュアクセスを行う際に渡されることが一般的です。ライブラリやSDKもメトリクスライブラリと連携しており、インストルメンテーションが自動的に追加されます。これにより、各リクエストの情報が収集され、デバッグ時に役立ちます。 リクエストに関する情報には、誰がリクエストを行ったか、どこから来たか、インフラストラクチャの情報、どのアベイラビリティーゾーンやキャッシュノードを使用したか、処理時間や処理済みリクエスト数など、タイミングや数値データが含まれます。 一般的には、これらの測定値はタイミング、数値、事実、属性（文字列）のカテゴリに分類されます。メトリクスシステムは、これらの測定値をメトリクスに変換する方法を知っている必要があります。そのため、メトリクスの定義が行われます。 これらの概念は、メトリクスを確認するために使用されるさまざまなツールにも適用されます。たとえば、CloudWatchを使用して全体的なレイテンシをプロットする場合などです。各メトリクスには、定義が存在します。このようなEMF（埋め込みメトリクスフォーマット）レコードは、製品情報サービスに関する情報がJSON形式で格納されていることを示しています。

ディメンションについても細かく分類せず、リクエストのタイム属性を利用します。これらのメトリクスを見ることで、製品情報サービスの遅れや問題がどのAPIで起こったのかを把握することができます。 次に、メトリクス測定値とディメンションを利用して便利な分析を行う方法が述べられています。ディメンションは、アベイラビリティゾーンやAPIなど、測定結果を分類するために使用されます。しかし、カーディナリティの高いデータ（インスタンスごと、製品ごと、顧客ごとなどのデータ）を分析するには、さまざまなツールが必要になるとしています。 これらのメトリクスとディメンションを適切に利用することで、問題の原因を特定し、サービスの改善に繋げることができます。

すべてのリクエストとそれらに関する情報がログに記録されるため、ログ分析ツールでデータを異なる方法でスライスしたり、ビンに入れたりできます。これにより、事前に定義されたメトリクスを使用せずに、さまざまな次元でクエリを実行してデータを分析できます。また、特定の問題のトラブルシューティングにも役立ちます。 プロファイリングは、本番環境で行われることがあり、パフォーマンスの検証や改善をサポートします。プロファイリングにより、実行時間の長いコードの部分を特定し、問題を解決できます。生のログデータで、障害や潜在的な問題を特定し、あらゆる次元での質問に答えることができます。例えば、リクエストがあるタイミングでエラーになった時、どのようにそのエラーが起こったかをログデータから把握することができます。これを通じて、問題解決に繋げることが可能です。

15 高いカーディナリティ メトリクスの分析

現代のシステムやアプリケーションでは、非常に重要な質問がしばしば高いカーディナリティを持つメトリクスに関連しています。そして、我々はそれらの質問に答えられるようになりました。今、私たちが本当に興味を持っているのは、何が起こっているのか、そしてその針が実際にどこにあるのかということです。 例えば、EC2 インスタンスのフリートがあり、それらすべてにエラーが生じている場合、そのエラーは本当に全体に広がっているのでしょうか。それとも、インスタンスのうちの一部だけに限定されているのでしょうか？ このような状況では、インスタンスごとのすべてのメトリクスを取得して分析する必要があります。 さらに、さまざまな顧客がさまざまなタイプの影響を受ける場合も同様で、すべての顧客に対して調査を行うことはできません。そのため、データをフィルタリングする方法が必要となります。これらの高いカーディナリティディメンションには非常に興味深い質問がいくつもありますが、すべてを一度にプロットし、目で理解することはできません。 ここで、高いカーディナリティメトリクスの分析に役立ついくつかのツールが登場します。その1つが、CloudWatch Metrics Insights　です。このツールを使えば、API ごとのディメンションをプロットして分析することができます。さらに、特定の件数だけを表示する「指定レコード数」の機能などもあります。 しかし、非常に高いカーディナリティのケースでは、それぞれの場合で異なるメトリクスが必要であることが珍しくありません。そのような場合には、CloudWatch Contributor Insights を利用することができます。このツールは、すべての個別の値をチェックするだけでなく、メトリクスを作成して追跡することができます。 具体的には、CloudWatch Contributor Insights は、数多くの値から必要なものだけを表示し、それらだけを追跡するために非常に役立ちます。このようなツールを活用することで、高いカーディナリティを持つメトリクスを効果的に分析することが可能になります。 最終的には、高いカーディナリティのデータを分析するためには、目的や状況に応じて適切なツールやアプローチを選択することが重要です。そして、その選択を通じて、高いカーディナリティを持つメトリクスから得られる情報が、システムやアプリケーションの改善に繋がっていくことでしょう。

16 クライアント障害　vs. サーバー障害

私たちは自身のコードが失敗した場合や問題が発生した場合、それをゼロにする必要があります。また、サーバーの障害である500エラーも制御できるようになりたいです。しかし、クライアント側の障害も重要で、顧客が誤ったリクエストを送信した場合や承認や認証がされていない場合などです。これらの問題をどのように理解し、対処するべきでしょうか。 サーバーの障害を監視して警告する必要がありますが、同時にクライアントの障害にも注意を払う必要があります。 悪意を持つ者が不適切なパラメーターで呼び出しを始める可能性もあるためです。 一方で、ページャーをオフにしてしまうような状況もあります。 例えば、バグが生じたサービスをコード化してしまったり、入力値を短く制限してしまった場合、これらの影響でサービスが失敗するかもしれません。また、以前は渡せたより大きな入力値が変更により失敗し、気付かないことがあります。 ただし、これらの問題を完全に無視することはできません。問題が発生した場合、私たちは知りたいと思い、顧客と話し合いたいと思います。特に、私たちのAPIを使用する際に問題が発生することは厄介です。顧客と協力して問題が発生していることを知る必要があります。 その際に役立つのが、オブザーバビリティです。Contributor Insights というツールを使用することで、クライアントごとのエラーが表示され、問題を特定しやすくなります。このグラフを見れば、問題が一部の顧客で発生しているのか、広範囲に渡る問題なのかが分かります。 ただし、すべての問題に対してアラームを設定することはできません。その代わりに、カーディナリティと次元の考え方を組み合わせて使用することができます。例えば、エラーが発生したリクエストの割合を表示するグラフを作成することができます。これは、エラーのあるリクエストの数をリクエストの総数で割った値です。 また、エラーのあるクライアントのパーセンテージを表示するグラフも作成できます。これは、エラーのあるクライアントの数をクライアントの総数で割った値です。この方法で、エラーのある顧客の数を顧客の総数で割って、時間の経過とともにプロットすることができます。これにより、問題の発生と共に対処法を見つけることが容易になります。

CloudWatchは Metric Math をサポートし、Contributor Insightsはトップエンドと個別の値の合計数を追跡します。この Metric Math のアイデアをContributor Insightのユニークな Contributor（貢献者）と組み合わせて使用できます。2つのルールがあります。1つはエラーのある顧客を追跡するもので、もう1つは顧客ごとのリクエスト全体を追跡するものです。2つを　Metric Math　で除算し、アラームを作成できます。これにより、エラーが発生したクライアントの割合が得られます。これは、次元概念を非常に便利な方法で適用したものです。 これで、問題がどこにあるかをより詳細に理解できるようになりました。ただし、これが常に問題の原因を特定するとは限りません。データを事前に計画していなかった方法で集約しなければならない場合があります。例えば、AWS IoT コアチームで働いていた時に、多くのデバイスを持つお客様の問題のトラブルシューティングをサポートしたことがあります。デバイスはAWS IoTと通信し、データが分析アプリケーションに転送されていました。 定期的に、これらのデバイスが分析アプリを過負荷になる問題がありました。しかし、1秒あたりのリクエスト数のグラフがキャパシティーラインを下回っていたため、アプリが過負荷になっている理由は明らかでありませんでした。結局、1分あたりのリクエスト数を60で割ることで、平均リクエストレートが得られました。 問題は、デバイスがアイドル状態になり、5分おきにすべてのデバイスが起動しデータを送信し、1秒後に再びスリープするということでした。これを解決するためには、ジッター（ばらつき）を導入する必要がありました。しかし、これが分かったのはどうしてでしょうか？ 問題が分かった理由は、リクエストのジッター、つまりリクエストのばらつきを考慮しなかったためです。速度の平均値だけを見ると、問題が見えにくいことがあります。しかし、個々のリクエストのタイミングを見ることで、デバイス間の同期や集中的な負荷が発生していることが見えてきます。そのため、リクエストのパターンやタイミングを詳細に分析することで、原因を特定し、適切な対策を講じることができます。

17 例: 非効率的なコード

私たちは皆、コードを書いた経験があります。少なくとも、私は自分のキャリアでそれがあることを認識しています。そのため、このコードの一部が遅く動作して実行できないかもしれないので、ここで強調しています。しかし、Davidが話していたように、必ずしもコードの周りにタイマーを追加するわけではありません。多くの時間をかけていても、いつもコードにタイマーがあるわけではありません。それでは、本番環境でそのような問題をどのように観察しましょうか？ここでプロファイリングが非常に役に立ちます。 つまり、プロファイラーは、コードのさまざまな部分でどれだけの時間がかかっているかを示します。それが待機時間なのか、実際のCPU時間なのか。それにより、画面に表示されているようなフレームグラフが表示されます。グラフの一番下がアプリケーション全体で、一番上がこれらの静的な効率性の無いタイプです。棒が広いほど、関数はより多くのCPUや時間を消費しています。一番上のボックスは、スナップショット時点でのCPUの機能を示しています。 以前はプロファイリングをオフラインで行ったり、デスクトップで実行することが多かったですが、それでは本番環境から得られる価値と学びを逃してしまいます。そのため、Amazonでは常にプロファイリングを構築し、利用可能にしています。これにより、コードを最適化しようとしているだけでなく、何が起こっているのかを調べたい運用イベント中にもプロファイリングをチェックできます。 プロファイリングを使うことで、イベント前にコードのパフォーマンスを観察したり、イベント中に予期せぬ遅延が発生したコードの部分を特定したりできます。これは非常に便利な機能です。私はそれについて長く考えるつもりはありませんが、Lambdaなどのサービスを使っている場合、インストールは非常に簡単で、ワンクリックで済みます。 私自身のCloudWatchでの経験から言うと、私のチームはプロファイリングを見るだけで、可用性やレイテンシが改善される素晴らしい運用上の勝利を収めています。さらに、Amazon CodeGuruでも同様のことができます。これにより、「オブザーバビリティ」が向上し、コードの効率性が大幅に向上します。

18 根本原因の発見

ここでは、根本原因の発見に必要な幅広い範囲のオブザーバビリティ機能や、それを最適化するためのベストプラクティスについてお伝えします。根本原因の発見には、単一のテクニックやツールだけでは十分ではなく、必要なデータを簡単に利用できるようにし、待ち時間を短縮することが重要です。 メトリクスは、この課題を解決する典型的な方法ですが、問題がより深刻な場合もあります。そんな時、カーディナリティが増加するにつれて、何百、何千行ものデータが必要になります。Contributor Insights、Metric Insights、Log Insightsといったサービスは、こういった場面で役立ちます。運用イベント中に何かが遅くなったり見つけにくくなったりした場合は、次回から簡単にアクセスできるような形でデータを整理しておくことが重要です。このようなデータ整理は、確固たるロギング戦略を持つことによって支えられています。 根本原因を見つける方法の詳細を説明したので、この章では、Amazonが採用したベストプラクティスをいくつか紹介し、さらに有用なオブザーバビリティデータを取得する方法を解説します。カスタマーエクスペリエンスを最適化する方法についても触れます。

あらゆる箇所から測定

19 システム監視

分散システムにおいて、Amazonの優れたチームは複数のダッシュボードを用いて、システムのパフォーマンス変化を把握しています。しかし、通常のカスタマージャーニーでは、複数のAPIやコンポーネントを使ってユースケースを完成させる必要があります。私がAmazonで取り組んだ最初のプロジェクトでは、全体的なレイテンシーとオブザーバビリティを改善することが目標でした。CloudWatchコンソールを使用していたものの、顧客が実際にどのような状況を経験しているのかという疑問が常に付きまとっていました。特定の時間帯には、コンソール上で一連のテストを行うことができました。 分散システムを監視する上での重要性がますます高まっている中、複数のダッシュボードを活用し、適切なAPIやコンポーネントを使用してカスタマージャーニーを最適化することが求められています。また、全体的なレイテンシーとオブザーバビリティの改善がプロジェクトの成功に直結しているため、クラウドサービスの活用や専門知識の習得が不可欠です。各企業やチームが取り組むべき課題は、システムの監視をより効果的に行い、顧客の利便性を向上させることです。 そこで、適切なツールや手法を駆使して、時代に即したシステム監視を実現することが重要となります。

20 ブラウザ テストの解決

APIの動作検証が完了しましたが、ユーザーエクスペリエンスのテストは複雑な課題があります。顧客のブラウザバージョンやOS、モバイルクライアント、クライアントの遅延などが影響するため、一貫して良いエクスペリエンスを提供することが難しいのです。 そこで、ヘッドレスブラウザを使ったテストフレームワークを開発し、本番環境でサービスを継続的に検証・テストすることにしました。これにより、以前は見つけられなかったバグや問題を発見できるようになりました。また、問題のデバッグが容易になる機能も提供しています。 このサービスは、AWSの外部サービスとして2020年に開始され、CloudWatch Syntheticsと呼ばれています。APIやユーザーエクスペリエンスを常時監視し、モジュラーカナリアスクリプトを使用してアプリケーションの課題を検出できます。 さらに、CloudWatch Real User Monitoring（RUM）を構築し、実際の顧客がどのようなアプリケーション経験を持っているかを把握することができるようになりました。これにより、ナビゲーションイベントやJavaScriptのエラー、HTTPエラーなどのパフォーマンスデータが取得できます。 ただし、現在はあらゆる場所からデータを取得しているため、アラームの数が多く、オペレーターがアラーム疲労に陥る可能性があります。一部の顧客は何百万ものアラートを生成し、エンジニアやオペレータがアラームのトリアージやインシデントの原因特定に時間がかかることがあります。 Amazonでは、この問題に取り組むために独自のシステムを開発し、開発者が運用上の問題を検出できるようにしました。これにより、オブザーバビリティが向上し、より良いユーザーエクスペリエンスを提供できるようになりました。

21 複合アラーム　（Composite Alarms）

複合アラームとは、ブール論理を使用してアラームを集約することを主たる概念としているものです。例えば、1つのホストに障害が生じた際には、自動化を駆使して解決が可能ですが、何百ものホストで障害が発生した場合、人間が関与してチェックアウトする必要があります。 Amazonでは、複合アラームが好まれており、急速に普及しています。 複合アラームはAmazonの運営にとって非常に基本的なものであり、2019年にCloudWatchの独立した機能として発表されました。 現在、複数のお客様が複合アラームを利用されています。特に、英国のBT社が、CloudWatch複合アラームを使って英国中の数百万のスマートホームルーターデバイスを監視しており、EMFや複合アラームなどを用いてデバイスごとのログデータを取得しています。 これにより、集約されたメトリクスの階層を作成し、アラームの対応階層で表示することができます。その結果、運用イベントが発生している地域ごとに、ロケールごとの三角測量（データを集める手法を複数にすること）を行い、迅速に対応し、問題を早期に解決することが可能となります。BT社の具体的な方法については、参考にできるブログも存在しています。

まとめ

以上に述べたことから、オブザーバビリティを適切に利用するためには、顧客体験を完全に測定できるように、あらゆる場所から測定することが必要だと考えられます。オブザーバビリティの適用には3つの異なるカテゴリが存在し、顧客が見ているものを理解し共感できるように、干し草の山を掘り下げるようなヒントが必要です。

22 オブザーバビリティの継続的な改善

オブザーバビリティのツールキットには多くのツールが含まれており、それらはレイヤー構造を作り出しています。しかし、私たちが目指すべきは、これらのツールを活用し、具体的な質問に最適な答えを見つけ出すことです。このため、スタックやツールチェーンを効果的に利用すべきです。 まず、アラームは重要な信号であるものの、最も正確とはいえません。その次にサービスマップやダッシュボードを使用することで、情報をより正確に把握し、解決策に近づくことができます。トレースは、状況によってはルート原因への到達を迅速に行う上で効果的です。一度有益な情報を得ることができれば、次回その情報を手に入れることが簡単になるように改善を図るべきです。 Amazonのオブザーバビリティでは、継続的改善を歓迎する文化を持っているので、インストルメンテーションやログ、メトリクス、アラームを追加することにより、次回に起こった際に良い質問ができるようになります。これにより、問題解決が簡単になるので、より興味深い質問に取り組むことができます。 より良い顧客体験を追求する上で、ダッシュボードを見て質問を繰り返し、深く理解することが重要です。問題が発生した場合は、ログ解析に時間を投資し、トップレイヤーの情報を得ることで、迅速な解決策を見つけ出すことができます。オブザーバビリティを活用するジャーニーは、それらの改善と理解の繰り返しを通して進められます。

本セッションの内容に興味を持たれた方は、上部のリンクからセッション動画、セッション資料をご覧ください。